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Abstract 

The  U.S.  Naval  Observatory  (USNO)  Alternate  Master  Clock  (AMC)  became  fully  operational  on 
23  July  1996.  The  AMC  was  relocated  to  Falcon  Air  Force  Base  (AFB)  from  Richmond,  Florida, 
commencing  24  October  1995.  By  placing  the  AMC  at  Falcon  AFB,  the  clock  is  co-located  with  the 
GPS  Master  Control  Station  and,  thus,  the  primary  means  of  global  time  dissemination.  The  AMC 
is  in  a  key  position  to  provide  significant  improvements  to  the  various  space  systems  operated  by 
the  Air  Force  from  Falcon  AFB.  Efforts  are  underway  to  enhance  the  timing  of  GPS,  the  Air  Force 
Satellite  Control  Network,  and  some  TALON  programs  within  the  Space  Warfare  Center.  The  AMC 
will  be  able  to  provide  a  more  reliable  and  robust  timing  source  for  all  users  at  Falcon.  This  will 
eventually  lead  to  reduced  navigation  errors,  increased  communications  capability,  and  improvements 
in  C4I.  The  areas  in  which  the  AMC  will  be  used  to  enhance  worldwide  military  operations  are 
highlighted. 


INTRODUCTION 

The  U.S.  Naval  Observatory  (USNO)  Alternate  Master  Clock  (AMC)  is  the  backup  for  the 
Master  Clock  maintained  at  USNO.  The  move  of  the  AMC  to  Falcon  Air  Force  Base  (FAFB) 
occurred  between  October  1995  and  July  1996.  The  AMC  was  previously  located  in  Richmond, 
Florida.  The  clock  was  relocated  for  several  reasons: 

1.  Richmond,  Florida,  was  highly  susceptible  to  natural  occurring  problems,  such  as  hurricanes 

2.  Co-locate  with  the  Global  Positioning  System  (GPS) 

3.  Place  in  a  more  secure  environment 

4.  Provide  a  greater,  more  robust  backup  capability. 

The  AMC  is  designed  to  provide  precise  time,  on  the  order  of  2-3  ns  accuracy  a  day  to  the 
military  commands  located  at  FAFB.  The  primary  user  of  AMC  data  is  GPS.  Additionally,  the 
system  provides  timing  reference  signals  to  the  50th  Space  Wing  communications  squadron  and 
the  Air  Force  Technical  Applications  Center  detachment.  Plans  are  in  place  to  provide  precise 
timing  reference  signals  to  the  Air  Force  Satellite  Control  Network,  Space  Warfare  Center,  and 
other  satellite  control  systems. 
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This  project  was  coordinated  with  the  Air  Force  and  serves  to  support  the  interest  of  both 
services.  The  AMC  obtained  initial  operational  capability  in  November  1995  and  was  made 
fully  operational  on  23  July  1996.  The  next  major  step  in  the  development  and  operational 
use  of  this  system  occurred  on  12  September  1996.  On  this  date,  the  AMC  provided  a  5  MHz 
signal  to  the  GPS  Monitor  Station  located  at  the  Master  Control  Station  (MCS). 

WHAT  COMPRISES  THE  ALTERNATE  MASTER  CLOCK 

The  AMC  primary  equipment  consists  of  11  cesium  atomic  clocks,  2  hydrogen  masers,  2 
Auxiliary  Output  Generators  (AOGs),  data  analysis  equipment,  two-way  satellite  time-transfer 
systems,  and  distribution  systems.  The  two  master  clocks  at  the  AMC  are  the  AOGs,  with  each 
AOG  referenced  to  a  hydrogen  maser.  The  master  clocks  are  named  AMC  #1  and  AMC  #2. 

Data  on  all  AMC  clocks  are  gathered  using  two  separate  data  analysis  systems:  the  Data  Ac¬ 
quisition  System  (DAS)  and  the  Timing  Solutions  Corporation  Measurement  System  (TSCMS). 
The  DAS  compares  all  AMC  and  GPS  clocks  to  AMC  #1  and  AMC  #2  every  20  minutes, 
while  the  TSCMS  compares  the  5  MHz  frequency  of  all  AMC  clocks  to  AMC  #2  every  20 
seconds.  These  data  are  used  both  in  the  time  scale  and  for  analysis  of  clock  performance. 

The  AMC  has  three  GPS  receivers:  two  Precise  Positioning  Service  (PPS)  keyed  and  one 
Standard  Positioning  Service  (SPS)  unkeyed  timing  receiver.  The  PPS  receivers  are  made  by 
Stanford-Telecom  and  the  SPS  receiver  is  made  by  Allen  Osborne  Associates.  The  PPS  receivers 
are  used  to  monitor  the  GPS  satellite  clock  performance  and  provide  a  steering  reference  to 
AMC.  The  SPS  receiver  is  used  to  conduct  common-view  time  transfer  between  the  AMC  and 
USNO  in  Washington,  DC. 

The  AMC  maintains  the  highest  precision  reference  to  UTC(USNO)  using  Two-Way  Satellite 
Time  Transfer  (TWSTT).  The  means  of  distributing  AMC  to  users  is  via  a  5  MHz,  1  pps, 
or  I  RIG  B  distribution  amplifier.  Additionally,  many  outside  users  connect  into  the  AMC 
using  a  fiber-optic  cable.  The  AMC  also  has  a  redundant  telephone  voice  announcing  system. 
The  phone  number  is  (719)  567-6742.  In  the  future,  the  AMC  will  have  a  computer  modem 
capability. 

The  AMC  #1  has  maintained  time  to  within  two  nanoseconds  of  the  USNO  Master  Clock  in 
Washington,  DC.  This  is  made  possible  using  the  TWSTT  system.  Hourly  the  AMC  and  USNO 
establish  communications  via  a  commercial  Ku-band  satellite  to  exchange  timing  data.  AMC 
#1  is  then  steered  towards  the  Master  Clock  using  a  steering  algorithm  developed  by  Paul 
Koppang  (USNO).  AMC  #2  is  steered  to  USNO(GPS)  using  the  data  provided  by  a  keyed 
Stanford-Telecom  receiver. 


WHO  NEEDS  PRECISE  TIME? 

Many  users  rely  heavily  on  precise  time  and  precise  time  intervals.  For  instance,  GPS  uses  time 
at  the  nanosecond  level  for  precise  navigation  and  positioning  of  military  units  and  weapon 
systems.  The  military  communication  system  needs  precise  time  at  this  same  level  for  the 
synchronization  of  secure  communications. 

Time  is  disseminated  to  Department  of  Defense  (DoD)  users  by  many  means.  USNO  primary 
time  dissemination  means  is  using  GPS,  with  over  95%  of  military  users  relying  on  this  means 
of  dissemination.  GPS  provides  nanosecond  level  accuracy  to  users  on  a  continuous  global 
basis.  Other  methods  of  time  dissemination  and  their  accuracies  include: 
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1.  Two-way  Satellite  Time  Transfer  (TWSTT)  (nanosecond) 

2.  IRIG-B  (microsecond) 

3.  Internet  (millisecond) 

4.  Computer  modem  (millisecond) 

5.  Voice  (second) 

6.  PTTI  Advisory  Service  (bulletins-postprocessed  data). 


BENEFITS  OF  THE  ALTERNATE  MASTER  CLOCK 

In  the  event  of  a  loss  of  the  USNO  Master  Clock,  the  AMC  will  be  the  time  standard  for 
DoD  and  will  operate  using  an  independent  time  scale.  This  time  scale  will  be  based  on  the  11 
cesium  atomic  clocks  and  2  hydrogen  masers.  The  AMC  time  scale  is  automatically  computed 
hourly  and  manually  computed  twice  per  week.  Many  of  the  functions  of  the  USNO  Master 
Clock  will  be  performed  by  the  AMC;  however,  some  may  be  conducted  at  a  reduced  level  of 
support. 

The  installation  of  the  AMC  has  enabled  the  direct  monitoring  of  the  Falcon  GPS  Monitor 
Station  cesium  clock.  The  hydrogen  masers  located  at  the  AMC  allow  for  special  testing  with 
classified  users.  The  hydrogen  masers  will  maintain  an  accuracy  of  close  to  80  picoseconds  over 
a  period  of  one  week.  Plans  already  exist  to  conduct  a  special  timing  test  between  the  AMC 
and  the  Space  Warfare  Center.  This  testing  should  be  completed  within  the  next  calendar  year, 
with  data  available  in  1998. 

Eventually,  USNO  plans  to  establish  a  distributed  master  clock.  This  distributed  master  clock 
will  consist  of  the  AMC  time  scale  integrated  into  the  USNO  Master  Clock.  This  will  result 
in  a  more  robust  system  and  should  improve  the  overall  stability  of  the  Master  Clock. 


TIMING  REQUIREMENTS 

The  discussion  of  requirements  must  be  addressed  when  referring  to  precise  time  and  its  uses. 
The  needs  within  the  DoD  include,  at  a  minimum,  the  following: 

1)  Communications 

a)  Secure  and  Crypto 

b)  Increased  bandwidth  utilization 

2)  Geo-location 

a)  Remote  sensors 

b)  Combat  ID 

c)  Cooperative  Engagement  Capability  (CEC) 

3)  Navigation 
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4)  Computers 

a)  Data  recording 

b)  Network  Time  Protocol  (NTP) 

c)  ATM/SONET 


The  impact  of  improved  timing  for  GPS  in  the  future  is  significant.  The  integration  of  timing, 
from  GPS,  will  significantly  enhance  the  war  fighters  capability  to  meet  the  challenges  faced  by 
the  increased  operations  tempo.  GPS  in  the  cockpit  will  allow  the  pilot  to  not  only  improve 
his  navigation  picture,  but  also  improve  the  quality  and  accuracy  of  his  intelligence  picture. 
Improved  timing  on  the  battlefield  will  reduce  the  likelihood  of  friendly  fire  or  collateral 
damage.  Remote  sensors  will  realize  the  ability  to  provide  precise  intelligence  data  and  to 
communicate  these  data  to  the  war  fighter  with  greater  speed  and  accuracy. 

With  the  integration  of  good  internal  clocks  for  the  GPS  receivers,  more  reliable  tracking 
during  periodic  loss  of  the  GPS  signal  will  be  realized.  These  internal  clocks  will  significantly 
improve  the  Y-code  acquisition  time  for  authorized  users  and  require  fewer  satellites  in  view 
to  maintain  a  good  position. 


THE  PTTI  MEETING  AND  ITS  PURPOSE 

Following  this  talk  on  the  AMC,  a  significant  discussion  arose  regarding  the  need  for  precise 
time  and  the  focus  of  the  PTTI  Meeting  in  general.  The  requirement  for  precise  time  transcends 
many  levels  within  DoD  and  the  commercial  market.  The  impact  of  computers  on  everyday 
life  is  well  known;  however,  the  need  for  precise  time  is  not  as  well  understood.  For  instance, 
the  speed  of  a  computer  is  directly  tied  to  time.  A  100  MHz  computer  will  perform  an  internal 
operation  every  10  nanoseconds.  This  is  not  as  critical  in  a  stand-alone  mode  as  it  is  when 
operating  within  a  distributed  system  or  in  a  virtual  engineering  environment.  Here  remotely 
located  computer  systems  must  rely  on  accurate  timing  between  the  various  systems  in  order 
to  efficiently  perform  operations  and  transfer  data.  For  commercial  power  companies,  precise 
timing  at  the  nanosecond  level  allows  for  the  accurate  location  of  a  power  line  fault  in  times 
unimaginably  short  in  the  past. 

For  the  military,  more  accurate  timing  translates  into  putting  ordnance  on  target  and  minimizing 
or  even  preventing  collateral  damage.  In  order  to  make  this  a  reality,  time  must  be  known 
and  transferred  at  the  nanosecond  level.  The  fact  that  light  travels  at  186,000  miles  per  second 
means  a  nanosecond  equates  to  about  one  foot  in  linear  distance.  Thus,  if  two  or  three  remote 
sensors  identify  the  precise  time  of  the  occurrence  of  a  unique  event,  relative  to  their  location, 
then  the  exact  position  of  this  event  will  be  realized  and  effective  countermeasures  may  be 
launched.  This  assumes  the  sensors  are  all  referenced  to  the  same  time.  In  terms  of  mine 
warfare,  precise  timing  and  navigation  will  prevent  the  damage  or  destruction  of  an  ship  as  it 
transits  a  mine  field.  Why?  Because  the  exact  location  of  the  enemy  mines  will  be  precisely 
known  and  units  will  then  be  able  to  avoid  this  area. 

In  the  case  of  ships  at  sea,  timing  is  critical  to  communication  and  combat  systems.  For 
a  given  threat,  the  ship  may  have  less  then  30  seconds  to  detect  the  threat  and  provide  the 
necessary  response  prior  to  suffering  damage.  The  program  manager  responsible  for  developing 
this  system  provides  the  overall  time  line  from  detect  to  engagement  to  the  contractors.  But 
in  many  cases,  the  exact  breakdown  of  the  three  major  components  in  this  scenario  is  not 
known  or  defined.  Three  major  systems  are  key  to  the  success  and  all  rely  on  computers  and 
distributed  processing  systems  to  operate  properly:  1.  Detection,  2.  Command  and  Control, 
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3.  Engagement.  If  each  contractor  designs  their  system  to  meet  the  overall  time  line  (for 
instance,  30  seconds),  then  the  ability  of  the  system  to  counter  the  threat  will  not  be  realized. 
This  problem,  coupled  with  the  additional  ability  to  receive  threat  data  from  external  sources, 
compounds  the  processing  capabilities  of  today’s  computer  systems.  Therefore,  as  stated  earlier, 
the  ability  of  a  ship  to  respond  to  the  threat  may  very  well  depend  on  the  timing  accuracy  of 
the  entire  detect  to  engage  system  down  to  the  nanosecond  level. 

For  the  PTTI  Meeting  to  be  a  success,  the  right  people  need  to  be  in  the  audience.  Today’s 
state-of-the-art  equipment  and  high-speed  weapons  demand  the  attention  of  program  managers, 
engineers,  and  system  designers,  both  in  government  and  industry.  These  people  are  not  present. 
After  all,  what  is  the  purpose  of  the  PTTI  conference? 
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Questions  and  Answers 

ROBERT  VESSOT  (SMITHSONIAN  ASTROPHYSICAL  OBSERVATORY):  I  share  your 
concern  about  the  program  management;  I’ve  lived  long  enough  to  work  with  NASA  for  the 
last  30  years.  And  I  find  that  the  deterioration  of  program  management  has  gone  to  a  level 
now  where  there  is  more  concern  with  the  PERT  and  the  GANTT  charts  and  the  budgets 
than  any  conceivable  interest,  even,  or  understanding  technically  what  is  going  on.  Program 
managers  in  the  bad  old  days  -  or  I  should  think  the  good  old  days  -  used  to  be  engineers 
that  were  working  in  the  lab.  And  they  managed  outside  contractors,  but  they  had  a  very  clear 
perception  of  what  the  goals  were  and  how  to  get  there. 

Now  program  management  has  been  relegated  to  the  MBA;  and  even  though  I’m  at  Harvard,  I 
admire  the  school,  but  these  are  not  the  kind  of  people  you  want  to  manage  technical  programs. 
They  have  to  be  engineers  at  least  somewhere  along  the  line,  or  have  access  and  appreciation 
for  engineering. 

WILLIAM  BOLLWERK:  That’s  correct.  And  that’s  one  of  the  problems  we  do  face.  When  I 
was  a  program  manager,  I  had  GS-13s,  14s,  and  15s  who  had  no  knowledge  of  the  engineering 
that  they  were  dealing  with,  much  less  how  to  manage  it. 

JAMES  CAMPARO  (AEROSPACE  CORP.):  It  seems  we  keep  talking  around  this  issue  of  a 
disconnect  between  high-level  system  requirements  and  lower-level  PTTI  requirements.  And  I 
guess  one  thought  that  came  to  me  as  you  were  speaking,  would  it  be  beneficial  at  future  PTTI 
meetings  to  invite  program  managers  and  have  a  session  on  system  requirements?  Let  them 
tell  us  what  the  overall  system  requirements  are;  and  that  would  put  us  in  a  better  position  to 
try  to  translate  those  into  lower-level  PTTI  requirements  for  them. 

WILLIAM  BOLLWERK:  That  would  be  ideal  because  then  you  would  get  the  same  people 
in  the  room  to  be  able  to  communicate.  It  would  have  to  be  a  classified  session.  But  the 
other  thing  we  would  have  to  face  is,  what  program  managers  do  we  need  to  invite?  We  need 
to  know  what  systems  are  coming  down  the  line.  So  we  would  need  assistance  from  several 
sectors,  because  I  know  I’ve  stood  in  the  same  spot  Commander  Atkinson  has  here  and  have 
tried  to  find  out  the  requirements.  I  went  through  all  these  operational  requirement  documents, 
these  joint  operational  requirement  documents  and  none  of  them  addressed  timing.  Timing 
was  a  given;  it’s  going  to  be  there;  but  none  of  them  specifically  stipulated  that  I  have  a  timing 
requirement  and  I  have  a  timing  requirement  in  the  nanosecond  or  picosecond  or  microsecond 
or  millisecond  level. 

So  I  think  if  we  do  get  the  program  managers  in  here  and  we  get  some  sponsors  from  the 
Pentagon  in  here,  then  maybe  we  can  see  some  of  these  things  put  into  some  of  these  documents; 
and  then  maybe  we  can  start  heading  in  the  right  direction. 

LT.  OMAR  NAMOOS  (USAF):  I’ll  just  be  brief.  I  come  from  the  program  management 
community.  The  thing  about  putting  requirements  on  timing  is  ~  somebody  mentioned  it 
earlier  -  timing  is  really  a  derived  requirement.  I  as  a  program  manager  have  users,  war 
fighters  who  do  a  task  in  the  field.  And  I  build  my  requirements  -  at  least  we’re  trying  to 
do  it  and  we  think  it’s  a  smarter  way  -  is  to  say,  “build  me  a  box  that  does  this.”  And  that’s 
specified  at  the  performance  level. 

Timing  is  then  the  contractor’s  responsibility  to  say,  “In  order  to  perform  this  function  for  you, 
I  have  the  following  derived  timing  requirement.”  The  military  shouldn’t  be  in  the  business  of 
doing  that. 

C.APT.  KENT  FOSTER  (USNO):  As  a  career  oceanographer  and  weather  guesser.  I’m  used 
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to  being  in  a  lot  of  places  where  people  don’t  like  me  a  lot  because  of  what  I  have  to  say 
and  the  information  I  bring  to  them.  That  is  true  no  place  more  so  than  it  is  in  dealing  with 
program  managers  that  are  building  systems  that  are  susceptible  to  the  elements  of  weather  in 
the  ocean  and  combined  effects.  And  after  having  dealt  with  these  people  for  several  years, 
I’m  convinced  that  the  big  problem  is  that  weather  guessers  don’t  make  life  easier  for  operators 
or  for  people  who  design  systems;  they  make  life  more  difficult  for  them  because  they  bring 
them  problems  that  they  need  to  overcome. 

And  I  think  that’s  the  problem  that  we’re  coming  to  grips  with  here  with  timing.  We  don’t 
make  life  easier  for  program  managers,  and  it’s  veiy,  very  easy  and  very  desirable  for  them 
to  ignore  us  to  the  extent  that  they  possibly  can  and  get  away  with  it.  And  that’s  a  mindset 
that  you  really  have  to  come  to  grips  with  and  to  reconcile  and  overcome.  And  I  think  that’s 
probably  why  there  are  not  a  lot  of  program  managers  here. 

PHILLIP  TALLEY  (RETIRED,  AEROSPACE  CORE):  In  1992,  I  made  a  rather  sustained 
effort  to  organize  a  session  for  this  PTTI  that  would  bring  in  various  major  contractors  like 
G.E.  and  Lockheed  and  so  forth  to  let  them  explain  how  they  went  about  through  their 
systems  engineering  to  specify  time  and  frequency,  not  necessarily  by  a  specific  systems,  but  as 
a  corporation  how  they  went  about  doing  this.  And  I  got  some  early  indication  of  cooperation, 
but  absolutely  no  one  actually  participated.  And  I  tried  rather  hard. 

WILLIAM  BOLLWERK:  It’s  not  going  to  be  easy  to  get  the  program  managers  or  those  type 
of  people  in  here,  but  that  doesn’t  mean  that  we  should  stop  trying.  We  need  to  make  it 
happen  somehow. 

GERNOT  WINKLER  (INNOVATIVE  SOLUTIONS  INT’L):  I  think  the  core  problem  is  that 
timing  is  an  embedded  requirement.  And  as  you  said,  it  is  left  to  the  contractor;  that  means 
that  every  contractor  is  going  to  solve  it  in  his  own  way.  This  is  a  very  expensive  procedure; 
duplication  is  a  consequence  of  that.  And  that  is  the  reason  why  there  is  a  PTTI  instruction  - 
or  has  been  -  in  order  to  take  it  out  and  make  sure  that  there  is  some  coordination  between  all 
these  individual  embedded  requirements  which  otherwise  would  solve  the  problem  of  bringing 
time  to  Hawaii  or  Kwajalein  or  wherever.  We  have  to  have  a  concentrating,  coordinating  center 
for  that. 

CAPT.  KENT  FOSTER:  I  think  the  solution  is  embedded;  there’s  no  doubt  about  it.  But  I 
don’t  think  that  that’s  a  reason  why  the  stated  requirement  should  stay  embedded. 

GERNOT  WINKLER:  No,  no,  I  agree. 

RICHARD  GRIFFIN  (TEXAS  INSTRUMENTS):  A  couple  comments.  We’re  using  the  phrase 
“program  managers.”  I  think  the  working  people  who  do  what  you’re  talking  about  are  systems 
analysts,  systems  engineers.  They’re  the  ones  that  provide  the  actual  working  interface  between 
requirements  that  come  down  from  operational  command  and  the  technologies  that  exist.  That’s 
why  I  was  asked  to  come  to  this  program  by  my  company,  because  that’s  the  interface  area 
that  I  work. 

And  the  way  we  do  it  is  with  error  budgets.  As  the  Captain  said,  one  of  the  biggest  problems 
we  face  within  companies  and,  frankly,  with  respect  to  the  government,  there  is  today  a  great 
honor  about  hearing  about  problems.  If  you  go  into  a  meeting  and  do  an  error  budget  and 
say,  “We’re  going  to  have  a  problem  with  this,”  you’re  going  to  get  hit  hard  and  fast  because 
they  don’t  want  to  hear  about  problems;  they  don’t  want  anything  that  they  feel  will  jeopardize 
the  budget  cycle,  will  jeopardize  the  political  acceptability  of  a  program,  they’re  not  willing  to 
listen  to  it.  And,  of  course,  it’s  complicated  by  the  fact,  as  we  pointed  out,  that  many  of  them 
don’t  have  the  technical  expertise,  either  because  they  are  MBAs  or  they  were  engineers  30 
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years  ago;  and  that’s  the  technology  they  remember,  they  haven’t  kept  up. 

But  I  think  the  people  you  need  to  bring  in  would  be  for  a  session  on  systems  engineering 
associated  with  time.  Because  in  my  work  what  I  have  to  do  is  take  the  overall  requirements, 
derive  an  error  budget,  and  then  look  at  what  the  technology  capabilities  are  to  meet  that  error 
budget  and  go  back.  But  often  what  I  go  back  with  is  bad  news  or  poor  news.  And  you  need 
support  from  there. 

RANDOLPH  CLARKE  (USNO):  I  have  a  thought  on  the  idea  of  program  managers  here. 
I  think  any  program  managers  we  could  get  here  probably  don’t  need  to  come  here  because 
they’ve  already  got  the  idea.  So  we  should  turn  it  around  and  try  to  determine  where  the 
program  managers  are  in  the  first  place,  where  do  they  meet,  and  send  our  people  to  their 
meetings  and  start  opening  this  up.  Eventually,  then,  we  will  get  program  managers  here.  But 
we  have  to  make  an  outreach  to  where  they  are.  They  must  have  meetings  like  this. 

WILLIAM  BOLLWERK:  Actually,  they  don’t.  There’s  no  central  meeting  of  program  managers. 
Program  managers  are  enmeshed  in  their  own  programs  to  make  sure  that  their  programs  are 
executable,  as  is  pointed  out,  with  the  budgetary  and  other  cycles. 

And  also  there’s  the  big  picture  of  meeting  with  their  sponsor  in  the  Pentagon,  who  is  the 
resource  sponsor  for  their  funds.  And  try  to  then  coordinate  meetings  with  the  contractors  in 
industry  and  the  Fleet,  in  some  cases,  to  make  sure  that  everything  kind  of  comes  together. 

Program  managers,  though  you  said  they  probably  shouldn’t  be  heTe  -  I  tend  to  disagree  with 
that  because  they’re  going  to  help  come  up  with  the  solutions;  they’re  going  to  force  their 
people  to  come  with  the  solutions  one  way  or  another.  And  if  you  don’t  include  them,  then 
they  may  not  appreciate  the  detail  to  which  people  have  to  go  through  to  derive  some  of  these 
,  requirements;  because,  they  all  are  derived.  And  if  we  don’t  derive  them  properly,  a  little 
nanosecond  here,  as  you  translate  up  into  the  big  picture,  gets  lost,  and  pretty  soon  you  don’t 
meet  your  threat  or  your  requirement. 

HELMUT  HELLWIG  (USAF):  Try  to  bridge  this.  I  think  I  would  ask  this  audience  to  listen 
to  some  of  the  comments,  because  if  I  look  at  the  sequence  of  the  discussion,  it  is  as  if  one 
of  the  discussants  hasn’t  listened  to  the  previous  discussant.  And  I  wanted  to  endorse  what 
you  said,  it’s  a  systems  engineering  thing  that  we’re  talking  about,  not  a  program  management 
thing.  Let’s  have  the  definitions  clear.  There  are  meetings  of  program  managers,  and  I’m 
participating  in  those;  you  don’t  talk  about  this  kind  of  thing,  whether  it’s  time  or  any  other 
technical  detail.  Time  and  frequency  and  clocks  are  tools  of  systems  engineering,  and  in  a  big 
system  they  are,  yes,  an  important  tool,  but  one  of  many,  many,  many.  And  you  need  to  get 
together  a  systems  engineering  forum,  as  you  said,  and  try  to  bridge  the  gap  between  a  tool  of 
the  systems  engineer  and  the  systems  engineering  community.  Most  of  you  are  experts  in  the 
tool,  and  you  need  a  link  to  the  systems  designer;  that’s  not  the  program  manager,  a  program 
manager  is  not  the  systems  designer. 

And  in  the  future,  by  the  way,  as  a  consequence  of  acquisition  from  DoD,  more  and  more 
of  the  requirements  -  in  fact,  the  current  goal  is  all  requirements,  as  I  think  the  Lieutenant 
pointed  out  -  are  performance  requirements  as  seen  by  the  war  fighter.  And  it’s  up  to  the 
contractor  and  the  systems  engineer  to  translate  those  into  their  particular  system.  And  we 
will  not,  and  DoD  will  refrain  from  specifying,  what  clock,  what  time  system,  what  interface, 
except  if  it’s  an  interface  that  matters. 

DARRELL  ERNST  (MITRE  CORP.):  I  think  I  can  only  support  what  this  gentleman  just  said. 
I’ve  worked  in  this  area  for  many,  many  years,  and  it’s  not  the  program  managers.  Program 
managers’  eyes  glaze  over  even  when  they’re  directly  affiliated  with  the  problem. 
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I  feel  that  the  problem  is  a  lack  of  education  at  the  engineering  level.  Many  of  the  engineers 
that  work  these  problems,  these  systems  engineers,  go  to  a  catalog  and  they  find  a  number  of 
different  off-the-shelf  items  that  meet  their  requirements;  if  they  don’t,  they  call  around  until 
they  find  somebody  who’s  willing  to  modify  their  equipment  to  make  it  work.  And  then  they 
plug  it  together  and  they  run  their  tests  and  they  go  on.  And  Joe  White  [NRL]  can  support 
me,  I  think  he  watched  me  try  to  fight  a  problem  in  the  AFSCN  back  in  the  ’80s  when  we  were 
building  Falcon  Air  Force  Base.  For  years,  they  didn’t  know  it,  but  they  were  operating  at  the 
half  a  millisecond  error  in  their  timing  systems  because  they  were  transmitting  their  IRIG-B 
code  upside  down.  Engineers  looked  at  it  almost  every  day  and  didn’t  know  what  they  were 
looking  at. 

It’s  at  the  technical  level  that  we  have  to  solve  this  problem.  Program  managers  are  doing  their 
job,  they  fight  Congress  and  they  fight  all  the  different  people  that  are  forcing  requirements 
creep  on  their  projects;  they  don’t  have  time  to  worry  about  something  to  them  that’s  a  tiny 
little  part  of  a  huge  system.  We  did  a  requirements  analysis  on  some  comm  protocols,  and 
you  go  ask  program  managers,  or  even  their  systems  engineers,  and  say,  “What  are  your  comm 
protocol  requirements?”  And  they  say,  “What  are  you  talking  about,  what’s  a  protocol?” 

And  the  same  thing  with  time.  We’ve  got  the  problem  here,  not  at  the  program  manager  level. 
You  go  to  these  contractors;  the  contractor  is  going  to  take  a  junior  engineer  and  put  him 
on  this  because  we’re  talking  about  one  rack  of  equipment;  he  goes  to  the  TRAK  microwave 
catalog  and  he  picks  out  his  timing  equipment;  and  he’s  solved  the  problem,  he  thinks. 

JOHN  VIG  (ARL):  Maybe  what  we  need  is  a  product  liability  law  for  military  systems.  Because 
when  General  Motors  builds  a  car  and  gas  tanks  start  exploding  five  years  later,  General  Motors 
is  still  responsible,  and  gets  sued,  and  they  know  it  gets  very  expensive  if  they  design  a  defective 
product.  Unfortunately,  in  military  systems  it  doesn’t  work  that  way.  After  a  system  is 
delivered  and  things  start  going  wrong,  guess  who  pays?  It’s  always  the  taxpayer  who  pays,  not 
the  contractor  who  delivered  that  system. 

So,  in  an  ideal  world,  I  agree  with  Lt.  Namoos  that  the  government  should  not  be  specifying 
how  a  system  should  be  implemented;  they  should  be  specifying  only  what  the  system  should 
do.  That’s  absolutely  the  correct  way  of  doing  things.  But  if  you  do  it  that  way,  then  you  also 
have  to  have  much  better  specifications  for  the  system;  and  that  specification  probably  should 
include  lifetime  beyond  delivery  of  the  system  and  incentives  for  ... 

CAPT.  KENT  FOSTER:  Not  being  one  to  shy  away  from  controversy,  I’ll  add  one  comment 
to  this.  I  hear  all  that  about  the  systems  engineers,  and  I  don’t  disagree  with  it.  But  again, 
system  engineers  are  the  solvers  of  the  problem. 

In  my  mind,  there  clearly  has  to  be  some  accountability  maintained  over  the  systems  engineers. 
And  the  person  who  is  going  to  stand  up  and  explain  why  the  end  performance  level  doesn’t 
match  the  requirement  isn’t  going  to  be  the  systems  engineer,  it’s  going  to  be  the  program 
manager.  And,  therefore,  the  program  manager  needs  to  get  more  involved  in  addressing  the 
requirement  to  the  performance  level. 

WILLIAM  BOLLWERK:  And  to  complement  what  the  Captain  just  said,  I  think  a  clear 
example  of  that  is  Block  HR  and  the  satellite  that’s  going  up  in  a  couple  months.  It’s  going  up 
with  one  set  of  clocks  on  it;  it  was  specified  to  have  two  different  types  of  clocks:  rubidium, 
cesium.  And  the  fact  is  that  it’s  going  up  with  only  rubidiums. 

So  if  we  have  a  problem  with  those  clocks  and  that  one  set  of  system,  then  we’ve  completely 
thrown  away  a  satellite  in  space,  it’s  completely  useless  for  navigation  if  those  clocks  were  to 
fail.  And  that’s  where  if  the  program  manager  was  probably  more  aware  of  the  implications 
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between  rubidiums/cesiums  and  having  two  different  types  of  clocks  on  one  satellite  so  that 
you  don’t  suffer  a  manufacturing  defect  failure  or  something  else,  then  probably  we  wouldn’t 
be  in  that  situation.  We’ll  have  to  see  what  happens  when  the  satellite  goes  up,  but  that’s  a 
potential  problem  with  doing  something  like  that. 
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